Web services networks are rapidly evolving technology architectures allowing applications to tap into a variety of services in an extremely efficient and cost effective manner. Web services enable cost-effective and efficient collaboration among entities within an enterprise or across enterprises. Web services are URL or IP addressable resources that exchange data and execute processes. Essentially, Web services are applications exposed as services over a computer network and employed by other applications using Internet standard technologies, such as XML, SOAP, WSDL, etc. Accordingly, Web applications can be quickly and efficiently assembled with services available within an enterprise LAN or external services available over open computer networks, such as the Internet.
A Web services network can be deployed across an enterprise LAN or across a Wide Area Network, such as the Internet. A typical Web services network includes at least one network services broker that is operative to receive a service request and route the service request to the appropriate resource. A broker is a specially configured server or cluster of servers acting as an intermediary for Web service requests and responses. As Web services network usage increases, however, the broker can become a bottleneck. To ease this bottleneck, the prior art solution is simply to add additional processing power to the broker (e.g., additional servers), which is costly, inefficient, and fails to leverage the enterprise's investments in its existing network infrastructure. Moreover, the centralized nature of the broker creates reliability concerns in that failure of the broker disables the applications accessing services through it. Accordingly, U.S. application Ser. No. 09/990,722 discloses a distributed Web services network architecture that, among other things, alleviates the bottleneck and point-of-failure concerns discussed above.
“Pub-Sub” or Publish/Subscribe systems operative to disseminate data messages over computer networks are known. Publish/Subscribe systems generally refer to any electronic data transfer mechanism that supports a publish/subscribe model of information dissemination. For didactic purposes, such a model includes the following objects:                A topic, which is a named abstraction representing a particular subject. An example of one such topic might be PriceOfGoldInYen, which represents the current price of gold on the world market. Those interested in this topic presumably desire to receive timely updates concerning fluctuations in gold prices, as expressed in yen.        A subscription, which represents an agreement to receive information concerning a particular topic. Each subscription usually contains all data required for a system to deliver appropriate information to those who require it, such as the address of the recipient.        A topic message, which consists of data concerning a particular topic. A message sent to the PriceOfGoldInYen topic might simply be “40,000,” meaning the current price of gold in yen is 40,000.Furthermore, pub/sub model typically defines the following actors:        A publisher, who creates a topic.        A subscriber, who requests a subscription to a topic.        A publisher, who agrees to establish a subscription to a topic.        A publisher, who publishes information to a topic.As the terminology used above suggests, the paradigm at work in this model is largely borrowed from the print publication industry. Just as an individual might subscribe to a print publication, an electronic system, such as an application running on a networked server, is capable of subscribing to a topic. Furthermore, just as the individual would then receive issues of that publication as they are made available, an electronic subscriber would receive messages addressed to the designated topic as they are made available.        
Publish/subscribe systems differ from the more common request/response model, in which one system requests that another provide a particular item of information or carry out some specified activity, in several ways. First, once a subscriber has established a subscription to a topic, the subscriber need not make any additional requests concerning that topic—information relevant to the topic is sent unsolicited. In addition, the electronic messages that support a pub/sub model are logically unidirectional—instead of a request/response message pair, only a single message need be sent. Another key difference involves the number of participants in a pub/sub transaction. While request/response systems generally involve a single requestor and single responder, a given topic may have any number of subscribers, all of whom are sent messages published to that topic.
Because topics and subscriptions to those topics must by their very nature be stateful, any system that supports pub/sub messaging maintains a persistent representation of the relevant objects. These objects may be thought of, in the aggregate, as a “topic cloud” (see FIG. 1). A topic may be further conceptualized as a container for subscriptions to that topic, each one of which has been created in response to a subscriber request. The directed line segments in FIG. 1 represent directional message flow. Lines connecting publishers to topics represent topic messages issued by publishers, while lines connecting subscriptions with topic subscribers represent the flow of messages through a pub/sub system to the subscribers. For didactic purposes, FIG. 1 depicts the following:
1) Subscriber X has subscribed to topic 3.
2) Subscriber Y has subscribed to topic 3 and topic 2.
3) Publisher 1 sends messages to topic 1 and topic 3.
4) Publisher 2 sends messages to topic 2.
5) Subscribers U, W, and Z have subscribed to topic 1.
White systems currently exist that implement the pub/sub functionality discussed above, such systems generally require special effort or functionality to integrate with an enterprise's computer network architecture. For example, many pub/sub systems usually require that publisher and/or subscriber end systems include special-purpose functionality, such as specific libraries, proxies, stubs, etc., to publish and/or receive messages. In addition, such pub/sub systems fail to leverage existing Web services network functionality often deployed by enterprises.
In light of the foregoing and the rapidly expanding use of Web and network services, a need in the art exists for methods, apparatuses and systems that facilitate the deployment, configuration and support publish/subscribe systems within the context of Web services networks. In addition, a need in the art exists for technology that leverages existing Web services network infrastructure to create an efficient and cost effective publish/subscribe system. As described below, the present invention substantially fulfills these and other needs associated with publish/subscribe systems and Web services networks.